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REMARKS 

By this Amendment, claims 1, 60, 61, 63-65, 68, 69 and 73 have been amended in 
order to expedite prosecution and do not, by this amendment, intend to abandon subject 
matter of the claims as originally filed or later presented. Moreover, Applicants reserve the 
right to pursue such subject matter in a continuing application. Claims 1 and 57-75 are 
pending in this patent application. Reconsideration of the rejections in view of the remarks 
below is requested. 

On September 8, 2006, Applicant filed a Request for Continued Examination. Along 
with the Request for Continued Examination, Applicant requested a suspension of action 
under 37 C.F.R. 1.103(c) for 2 months. A copy of the Request for Continued Examination 
(including the request for suspension of action) is enclosed herewith. Accordingly, the period 
of suspension expires November 8, 2006. Applicant has filed this Amendment within the 
period of suspension and accordingly, requests that it be entered. See MPEP §7 14.03(a) 
("Supplemental replies will not be entered as a matter of right, except when a supplemental 
reply is filed within a suspended period under 37 CFR 1.103 (a) or (c) (e.g., a suspension of 
action requested by the applicant when filing an RCE)." (emphasis added)). Applicant was 
surprised to receive the Office Action mailed October 10, 2006 (hereinafter the Office 
Action). Accordingly, Applicant demands that, should this application not be allowed in the 
next Office Action, the next Office Action be non-final. 

Claims 1, 57-61 and 63-75 stand rejected under 35 U.S.C. §102(a) as being 
anticipated by United States patent no. 5,815,657 to Williams et al. ("Williams et al."). The 
rejection is respectfully traversed. 

As discussed previously, in Williams et al., a graphical representation of payment 
instruments is presented on the display to enable a consumer to select a payment method of 
their choice. Once a payment instrument is selected, a summary of the goods for purchase are 
presented to the consumer and the consumer enters an electronic approval for the transaction 
or cancels the transaction. Electronic approval results in the generation of an electronic 
transaction to complete the order. 

Williams et al. further disclose that their monetary system comprises a Certificate 
Manager 304 that manages the automatic downloading of a consumer's certificate from a 
bank, validation of a consumer's and a merchant's certificates and automatic requisition of 
certificate renewal. The system further includes a Payment Manager 306 that coordinates and 
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completes the payment request that is received from the merchant system. The payment 
request received contains the final GSO, Ship-To name, merchant certificate, merchant URL, 
coupons and the payment amount. The Payment Manager 306 then communicates with the 
payment related GUI component to interact with the consumer to authorize and complete the 
payment transaction. A user interfaces with the payment manager 430 via a user interface 400 
that responds to and sends a variety of transactions 410, 408, 406, 404 and 402. The 
transactions include obtaining the next record, payment record, receipt, acceptance of the 
payment instrument and GSO components. In turn, the payment manager 430 sends 
transactions 414 and receipts 420 to a wallet manager 422 and receives payment instruments, 
certificates and private keys from the wallet manager 422. The payment manager 430 also 
sends and receives transactions to a protocol manager 470 including a merchant's payment 
message 460, a consumer certificate and PK handle 450, a merchant URL 442, a payment 
440, a signed receipt 434 and a GSO, Selected Payment Protocol and Selected Payment 
Instrument 432. 

However, Applicant respectfully submits that the cited portions of Williams et al. fail 
to disclose, teach or suggest a method of managing reliance in an electronic transaction 
system as recited in claim 1 . 

Williams et al. fail to disclose teach or suggest "obtaining electronic signals representing a 
request for transactional financial assurance based on a transaction involving a subscriber, the 
transactional financial assurance not including a payment request or payment authorization of 
the transaction itself 

First, Applicant submits that the cited portions of Williams et al. fail to disclose, teach 
or suggest obtaining electronic signals representing a request for transactional financial 
assurance based on a transaction involving a subscriber, the transactional financial assurance 
not including a payment request or payment authorization of the transaction itself, as recited 
in claim 1. The Office Action indicates that "the Payment Manager [of Williams et al.] 
receives the request for transactional assurance (i.e., authorization to pay or payment) from the 
merchant." However, the cited portions of Williams et al. merely disclose a Payment Manager 
that acts as a conduit to direct a request for payment (not a request for authorization to pay 
because after all it is the consumer that is paying, not the merchant or the Payment Manager) 
by a merchant to a consumer, from the merchant to the consumer and to handle the payment 
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from the consumer to the merchant. There is simply no indication that the merchant makes 
any type of request to the Payment Manager for financial assurance as claimed regarding a 
transaction with the consumer. A request for payment is not a financial assurance provided 
regarding the transaction as claimed; rather, it is simply a request for a constituent component 
of the transaction. 

Similarly, there is no indication that the consumer makes any type of request to the 
Payment Manager for financial assurance as claimed regarding a transaction with the 
merchant. The Payment Manager simply manages the mechanics of a request for payment by 
a merchant and the payment by the consumer, the consumer and merchant assuming the risks 
regarding the transaction with each other, and is simply not configured to accept a request for 
financial assurance as claimed regarding a transaction. 

Williams et al. note that the "payment manager 430... receives payment instruments, 
certificates and private keys from the wallet manager 422". Respectfully, none of those are a 
request for anything. For example, a certificate generally may be an embodiment of subscriber 
assurance of an attribute of a subscriber. 

Further, as discussed above, the merchant in Williams et al. makes a request for 
payment by the consumer and the consumer can (or cannot) authorize the payment. However, 
these are merely the inherent components of the transaction. Claim 1 recites a request for 
transactional financial assurance based on the transaction, the transactional financial assurance 
not including a payment request or payment authorization of the transaction itself. Moreover, 
the request for payment by the merchant and the authorization of payment by the consumer in 
Williams et al. do not provide any form of financial assurance of the transaction. Each of the 
merchant and the consumer in Williams et al. surely realize that the other may be fraudulent, 
insolvent, etc. Thus, the system in Williams et al. is not set-up to provide financial assurance 
regarding the transaction; it merely makes sure that the payment request from the merchant 
properly reaches the consumer and that the consumer properly initiates the payment. However, 
if the consumer has no money, clearly the consumer's authorization of the payment assures 
nothing. Similarly, if the merchant has no goods, the request for payment assures nothing. 

Williams et al. fail to disclose, teach or suggest "determining whether to provide the requested 
transactional financial assurance based on at least the subscriber assurance" 

Further, Applicant submits that the cited portions of Williams et al. fail to disclose, 
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teach or suggest determining whether to provide the requested transactional financial 
assurance based on at least the subscriber assurance as recited in claim 1. While the cited 
portions of Williams et al. disclose that the Payment Manager receives and sends consumer 
and merchant certificates, they do not disclose, teach or suggest that the Payment Manager 
makes any decision based on any of those certificates, let alone whether to provide 
transactional financial assurance. 

The Office Action asserts that the "Payment Manager will not provide payment 
authorization if there is no receipt of a certificate message from the consumer". As noted 
above, payment authorization in the transaction between the consumer and the merchant is not 
the financial assurance as claimed. Further, Applicant requests exact identification where 
Williams et al. state that the Payment Manager will not provide payment authorization if there 
is no receipt of a certificate message from the consumer. From a quick review, Applicant 
could only find discussion of sending and receiving consumer certificates or sending or 
receiving certificates from a consumer. 

Williams et al. fail to disclose, teach or suggest "issuing electronic signals representing 
transactional financial assurance to a reiving party" 

The cited portions of Williams et al. also fail to disclose, teach or suggest issuing 
electronic signals representing transactional financial assurance to a relying party as recited in 
claim 1. As noted above, the Payment Manager is merely an intermediary to facilitate the 
transaction between the merchant and consumer and does not facilitate issuance of any type of 
financial assurance as claimed regarding that transaction. Further, the Payment Window of 
Figure 34 of Williams et al. does not involve issuing signals representing transactional 
financial assurance to a relying party. The Payment Window is merely a vehicle for the 
consumer to issue payment to the merchant. It does not provide any financial assurance to the 
consumer that, for example, goods will be received, that the merchant is in good standing, etc. 

Further, Applicant disagrees with the characterization in the Office Action of 
Applicant's earlier remarks. Applicant also requests clear and exact identification where 
Williams et al. disclose that "the Payment [M]anager of Williams will not authorize payment 
absent receipt of the customer's certificate." 

Lastly, as repeatedly asserted in the Office Action, and disagreed with by the 
Applicant, the payment authorization (or payment request) of the transaction between the 
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merchant and consumer in Williams et al. is not the financial assurance, and thus not the 
request for financial assurance, as claimed. 

Claims 57-62 depend from claim 1 and are, therefore, patentable for at least the same 
reasons provided above related to claim 1 , and for the additional features recited therein. 

For similar reasons as provided above, Applicant respectfully submits that the cited 
portions of Williams et al. fail to disclose, teach or suggest a computer program product, 
embodied in a computer-readable media, comprising instructions for causing a computer to 
effect a method of managing reliance in an electronic transaction system as recited in claim 
63. 

For example, Applicant submits that the cited portions of Williams et al. fail to 
disclose, teach or suggest creating a reliance request message specifying at least one aspect of 
the transaction upon which a relying party intends to rely as recited in claim 63. Further, 
Applicant submits that the cited portions of Williams et al. fail to disclose, teach or suggest 
causing electronic signals representing the reliance request message to be sent to a reliance 
server requesting a transactional financial assurance for the aspect of the transaction upon 
which the relying party intends to rely, the transactional financial assurance not being a 
payment request or payment authorization of the transaction itself as recited in claim 63. 

Claims 64-67 depend from claim 63 and are, therefore, patentable for at least the same 
reasons provided above related to claim 63, and for the additional features recited therein. 

For similar reasons as provided above, Applicant respectfully submits that the cited 
portions of Williams et al. fail to disclose, teach or suggest a computer program product, 
embodied in a computer-readable media, comprising instructions for causing a computer to 
effect a method of managing reliance in an electronic transaction system as recited in claim 
68. 

For example, Applicant submits that the cited portions of Williams et al. fail to 
disclose, teach or suggest receiving electronic signals representing a reliance request 
message, the message specifying an aspect of a transaction with a subscriber upon which a 
relying party intends to rely and requesting assurance for the aspect of the transaction as 
recited in claim 68. Further, Applicant submits that the cited portions of Williams et al. fail to 
disclose, teach or suggest determining whether to provide transactional financial assurance 
based on the reliance request message, the transactional financial assurance not being a 
payment request or payment authorization of the transaction itself, and generating electronic 
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signals representing an indication of whether transactional financial assurance is available as 
recited in claim 68. 

Claims 69-75 depend from claim 68 and are, therefore, patentable for at least the same 
reasons provided above related to claim 68, and for the additional features recited therein. 

Because the cited portions of Williams et al. fail to disclose, teach or suggest the 
claimed subject matter of claims 1, 57-61 and 63-75, Applicant respectfully requests that the 
rejection under 35 U.S.C. §102(a) of claims 1, 57-61 and 63-75 based on Williams et al. be 
withdrawn and the claims allowed. 

All objections and rejections having been addressed, it is respectfully submitted that 
the present application is in condition for allowance. If questions relating to patentability 
remain, the examiner is invited to contact the undersigned to discuss them. 

Should any fees be due, please charge them to our deposit account no. 03-3975, under 
our order no. 061047/0268225. The Commissioner for Patents is also authorized to credit any 
over payments to the above-referenced deposit account. 

Respectfully submitted, 




JGH 

P. O. Box 10500 
McLean, VA 22102 
(703) 770-7900 
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